home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Ham Radio 2000
/
Ham Radio 2000.iso
/
ham2000
/
packet
/
praf205e
/
dama.doc
< prev
next >
Wrap
Text File
|
1995-04-01
|
41KB
|
730 lines
ARRL : 8th Computer Networking Conference - October 7, 1989 - page 203-209
DAMA - A NEW METHOD OF HANDLING PACKETS ?
==========================================
by Detlef J. SCHMIDT, DK4EG Steinbrecherstr. 22 D-38106 BRAUNSCHWEIG
NORD><LINK e.V.
c/o Peter Glzow, DB2OS
Allensteiner Str. 5
D-30880 LAATZEN
Germany
Translation : Mark Bitterlich, WA3JPY
Reprint : Pierre Cornelis, ON7PC
Lately it seems we are hearing more and more stories about hams who are
having trouble using their local node or digipeater. It seems that the user
has no trouble hearing the digi, but the digi doesn't seem to hear the user
at all. The symptoms almost match those where the receiver at the digi site
is either dead or close to it. While that kind of failure is always a
possibility, it is not the subject of this article.
The condition that this paper will talk about is one where the above
symptoms do actually occur, but not from any lack of receiver sensivity.
Instead it is due to the digi's receiver hearing too many signals all at
once and the remote user pretty much gets lost in the "noise".
The reason for this becomes obvious when we consider that while all the
users may hear the digi/node just fine, they in many cases don't hear each
other. Thus in some cases, more than one station will transmit at the same
time causing packet collisions. This situation is referred to as "a hidden
station" problem, and for remotely located users access to his or her
favorite digipeater become difficult to impossible during rush hour
periods.
This is not a new problem, and in fact there are other services
experiencing the same difficulties. A real world example is ships on the
open sea trying to gain access to a communication satellite.
Several different experiments have been made to overcome this dilemma on
amateur packet radio. One possible solution that is being pursued is
through the use of full duplex digipeaters (BTMA), however there are
several disadvantages to this approach. In a full duplex the hardware
expense will normally be much higher and the system will occupy two
frequencies but will only realize the maximum throughput of one. A better
approach might be to increase the throughput by reducing the collisions on
a single channel system rather than spreading the load onto two channels.
It would be ideal if we could incorporate a system that did this with
something so minor as software change (such as replacing the EPROM in a
TNC) or by changing some operational parameters.
One of the methods used that attempts to solve the hidden station problem
while still using a single frequency is called DAMA (Demand Assigned
Multiple Access). A description of this method follows.
In a connection oriented protocol environment, an end user will try to
connect to the master (satellite) by means of a slotted ALOHA method
(channel access without any coordination). Collisions might occur during
this phase but they are tolerable since they are relatively rare. Once a
connect request is recognized by the master, the connecting stations
identification is added to the polling list and from this point on the
master controls all connected stations. Permission to send data is granted
by means of polls which might be included in ACK packets or even in
transferred data frames. so in this case a user will only be allowed to
transmit after receiving "permission" in the form of a poll sent from the
master station. Once permission is granted several frames might be
transmitted in a block. However, if the user does not respond within a
given time frame (say around 1/2 second) then the master assumes that the
poll got clobbered or the user never received it for some reason. The
master then passes permission to to transmit to all other active stations
and when completed comes back to the first user and gives him another
chance.
On the other hand, if the user (slave) actually receives the poll and
replies with sent I frames, the master will not acknowledge them until the
next time around after serving all the other active stations. If when
polled by the master, the user responds with an empty frame (Receive
Ready/Final), then the master will reduce the user in polling priority and
will skip him on the next time around.
As the activity on the frequency increases, the polling priority of
inactive users might be further decreased, but when these stations respond
with an I-frame they will again regain their original priority.
If you understand the description just given, you might think that you are
reading about AX.25 level 2 protocol and this is why DAMA has a chance of
working over amateur packet radio. AX.25 L2 provides all the protocol
elements that are needed to implement DAMA and no new syntax is required.
Most of the new functions required could be obtained simply by patching
existing operational parameters while the rest could be achieved by making
some minor changes to the TNC's firmware.
So how do we actually go about incorporating DAMA using AX.25 protocol ?
Due to the fact that there are no new syntax elements required, the
following description will only use standard AX.25 terms. Since CSMA
(Carrier Sense Multiple Access) as well as DAMA is used, please interpret
all future references DAMA as CSMA-DAMA. The term "poll" used throughout
this text in no way refers to the poll bit in the control field of packet
frames and this bit remains unchanged to ensure compatibility. The
different phases of the protocol will be described separately below.
Connect Establish :
-------------------
When a node attempts to connect to a user, the node adds the users ID to
it's polling list and begins to send SABMs to that station. If after a
certain amount of tries no UA is received, the user is assumed to be
inoperable and is removed from the polling list.
When a new user starts a connect sequence to the node, he begins by sending
SABMs to the master in a simple CSMA manner duplicating the existing method
used today. Collisions are possible during this phase, so it might be
necessary to repeat the SABMs several times until the node replies with a
UA. Once the node recognizes the users connection attempt, the users ID is
added to the polling list in a fashion very similar to the one used by
TheNet nodes (TheNet userlist) and the node (master) is now in control of
the uplink users station. After the user sends SABMs and the node replies
with a UA, the user replies with an RR0 to signal to the node that it had a
successful reception of UA.
Idle state :
------------
As long as no information transfer occurs between user and node, (idles)
then the node sends its polls as an RR with the corresponding count. If the
response by the user is just an RR#, then the time until the next poll to
the user will be lengthened to avoid unnecessary channel load. The exact
amount of time added is determined by the total channel activity.
If information transfer by other users on the node is high (as determined
by the number of I-frames being sent) then the amount of time added before
the next poll occurs to an inactive station is longer than in cases where
there is only very little channel activity. Thus when the frequency is
basically clear, the waiting times are reduced to a minimum so that no
decrease in channel throughput takes place. This is the principle of the
self-alignment mechanism of DAMA, where a channel is always regulated to
insure its maximum possible throughput.
If the node ever fails to receive an RR from the user (due to a collision
of the nodes poll or the users RR response) then the node will proceed on
to the other stations on its polling list. The node will come back and try
this station again after all the other users on its list have been
serviced. If after a certain number of transmitted polls this station still
has not answered, then it is considered to be unavailable by the node and
is dropped completely from the list. This is analogous to those "keep-alive
polls" that we have today.
Data transfer : Node --> User :
-------------------------------
There is no difference between regular CSMA and DAMA in this case. Because
it is always up to the master (node) to act first, it could send one or
more I-frames or a poll to the user. The user will acknowledge I-frames
immediately with an RR#, but could also send its own I-frames with the
corresponding count (having to correct the count on the sent I-frame serves
the same purpose as an ACK with AX.25). The meaning of the Poll/Final bit
remains unchanged.
Data transfer : User --> Node :
-------------------------------
As mentioned before, the node will send polls to all users that are
uplinked to it and the user will not respond until it receives this poll or
an I-frame from the node. It may be wise to point out that when a user is
polled he must always come back with some kind of response, even if it is
an RNR#. If the node fails to hear any kind of response from the user then
it assumes something went wrong (such as a collision) and moves on to the
next user on its polling list.
This method of always waiting for a poll before transmitting is the central
aspect used to avoid collisions in a situation where hidden stations exist.
This is in contrast to the usual CSMA method where several stations can
actually transmit at the same time. Additionally the problem of deadtime
collisions is resolved. Deadtime refers to the period from when the TNC
realizes the channel is free and starts transmitting, to when he has been
on the air long enough for other TNCs to recognize his carrier. This is
really not a rare case, as exemplified by the case where two or more TNCs
are waiting for a digipeaters carrier to vanish so that they can leap on
the frequency. Using DAMA the node will not acknowledge received frames the
instant it hears them. Instead it will first service all other uplinked
stations and then come back with an RR# to the sending stations I-frames
along with a poll to that station. This poll basically says "Have you got
any else for me ?".
Disconnecting :
---------------
If the master intends to cut the connection, it will send the usual
DISC-frame to the user. The user will then promptly respond with the
UA-frame (final bit set). If the node fails to receive the UA and again
sends a DISC-frame, the user will respond with a DM-frame. This is
identical to the actual CSMA version.
When the user wants to disconnect from the node, he will wait to send his
DISC-frame until polled by the master. AT this point it makes no major
difference whether the node responds to the user right away with a UA or
goes through another polling cycle to do so, however an immediate UA is
preferred.
UI-frames :
-----------
In CSMA as well as in a DAMA environment, the UI-frames are treated in a
special way. I.E. These frames are used to carry some information besides
the regular protocol traffic. Normally UI-frames are never sent from a user
to a node, and it is not good headwork to make a habit of making UI-frame
direct QSOs on the input frequency of a node. However, in contrast to a
duplex system, it is possible to actually do this. So although the rare
UI-frames will reduce the throughput to the CSMA value, it will not drop
the much lower ALOHA value that would occur with a duplex digi having a QSO
on its input frequency. UI-frames originated by the node are no problem
since all stations receive these frames.
Other protocol elements :
-------------------------
So we have gone from the beginning to the end in describing a complete DAMA
session. We have not translated each and every AX.25 element into one that
has a special significance to DAMA. This is not required since many of them
will keep their initial meaning. DM, RNR, REJ, etc will all be used as they
were before. The only deviation from the pure CSMA version is in the fact
that the users will only be allowed to transmit these frames after
receiving permission from the master (node) in the form of a poll. The node
will only transmit these frames after all other users on its list are
served by completion of one polling cycle.
Compatibility of DAMA and CSMA :
--------------------------------
One advantage of the DAMA method is that it does not require everybody to
change everything all at once. However as additional users convert their
TNCs to work with DAMA the more pronounced will become the increase of
throughput. Even stations that are waiting to switch over could help to
increase the areas throughput by changing a few operational parameters. For
example the delay between the reception of a frame and the TNCs response
(sometimes called T2 or DWAIT) should be reduced to a value under 1 second.
In addition the time interval from when an I-frame is sent to when the TNC
sends an RR# to ask for a pending ACK, should be set to a value that is
clearly higher than the time between two polls of the master (usually more
than 30 seconds at 1200 Bd).
To fully benefit from DAMA both the node and the user must work together in
the master/slave relationship. Assuming that the users TNC is capable of
both the normal and the DAMA mode, there still remains the problem of how
to tell the user to "turn DAMA mode on". There are several ways that this
could be done:
1. Automatic detection of the protocol version by means of the protocol
identifier byte or reserved SSID-octet-bits of the node (preferred
version).
2. Implementation of a channel specific parameter which controls the
protocol version.
3. Implementation of a new UPLINK command besides the current CONNECT
command.
4. Implement a further protocol element such as a SABM-frame (similar to
X.25) so that at connect time the node could alert the user to the
increased features.
In case #1 of the above it would be sufficient to tell the user to switch
DAMA mode only once, at connect time. This state would then remain in
effect until disconnect. However since there is no PID field in
SABM-frames this information has to be carried in some other way, such as
utilizing the dormant bit 5 of the master's SSID address field. It is
proposed that DAMA test versions set this bit to 0 to convey the necessary
information to the users TNC.
Conclusion :
------------
The existing AX.25 version was established in 1982 when packet radio was
not widespread as it is today. Most stations in the beginning were pretty
much equal and there was no distinction made between DTE and DCE functions.
However with the implementation of wide area networks not all stations are
performing the same function. In fact today the network nodes are acting in
DCE function considering their control and information exchanging aspects.
These functions will be better served with the implementation of DAMA.
The methods discussed in this article could increase the throughput on an
AX.25 channel tremendously. One advantage is the avoidance of system
breakdown which occurs with channel overload. Using DAMA, the throughput
will increase continuously up to its maximum. There is no foldback effect
like that which occurs using CSMA where at a special limit (above ca 60%)
the throughput is actually reduced.
There is also a strong "social" aspect of DAMA wherein even the weak
stations can work through the node reliably without being overpowered by
stations close to the node.
It is possible to make direct connections with other HAMs on the uplink
frequency unlike that of a duplex system. In addition the users TNCs still
retain the digipeater capability inherent in our present simplex system.
All protocol elements keep their original meaning which allows both
versions to be utilized on the same frequency, yet throughput increases as
more and more users switch over to the new method.
Literatur
Fox,T. AX.25 Level 2 protocol specifications AMRAD
Kauffels,F.J. Lokale Netze R.Mller Verlag
Mahle,C. Satellite Scenarios and Technology IEEE J. on selected
Hyde,G for the 1990's Areas in communication
Inukai,Th. May '87
Schmidt,D.J. DAMA, ein neues Verfahren fr cq-DL, 4/89
Packed-Radio?
Schmidt,D.J. Synchrone DF-Protokolle mit 6809-Micro- TU-Script BS '81
Computern in heterogenen Sternnetzen
Tanenbaum,A. Computer Networks Prentice Hall Verlag
-------------------------------------------------------- July 24, 1992 ---
Note by DB2OS: The full DAMA protocoll is implemented in the latest
version of TheNetNode (TheNet for PC) as a DAMA MASTER
and TheFirmware (WA8DED Hostmode for TNC2) as a DAMA
SLAVE by NORD><LINK. DAMA is also supported by TFPCX, a
resident AX.25 software TNC for the PC (only external
Modem required, no TNC) and by TFKISS (former TFPCR).
TFKISS emulates a TNC with TheFirmware and any TNC
can be used if it can be switched into KISS-Mode!!!
DIGICOM and BAYCOM Software also now supports DAMA.
DAMA is now used on several german TNN digipeaters and
the results are of great promise.
-----------------------------------------------------------
╔══════════════════════════════════════════════════════════╗
║ D A M A - UN NUOVO METODO DI TRATTARE I PACCHETTI ? ║
╚══════════════════════════════════════════════════════════╝
┌────────────────────────────────────────────┐
│ Detlef J. Schmidt, DK4EG │
│ Steinbrecherstr.22 D-3300 Braunschweig │
│ Translation: Mark Bitterlich, WA3JPY │
│ Traduzione: IW2HIG @ IK2JYT, Paolo │
└────────────────────────────────────────────┘
Ultimamente sembra di sentire sempre piu' storie riguardo a
radioamatori che hanno dei problemi usando il loro BBS locale o nodo.
Sembra che mentre l'utente non ha problemi a sentire il BBS, il BBS non
senta del tutto l'utente. Il sintomo che corrisponde quasi esattamente e'
che il ricevitore collegato al BBS e' morto o chiuso rispetto all'utente.
Questo tipo di problema e' sempre possibile, ma non e' l'argomento che
trattera' questo articolo.
Il caso che questo articolo trattera' e' quello in cui accadono i
sintomi precedentemente descritti, ma cio' non e' dovuto ad una mancanza
della sensibilita' del ricevitore.
Invece il problema e' causato dal fatto che il ricevitore del BBS riceve
troppi segnali tutti insieme e l'utente rimane coperto dagli altri segnali.
La spegazione di questo diventa ovvia quando consideriamo il fatto
che tutti gli utenti possono sentire il BBS/nodo molto bene, mentre in molti
casi i singoli utenti non si sentono l'uno con l'altro. Cosi' puo' capitare
che piu' di una stazione trasmettera' nello stesso istante causando la
collisione dei pacchetti.
La situazione e' chiamata problema delle "stazioni nascoste" e per gli
utenti lontani l'accesso al loro BBS favorito puo' diventare difficoltoso
se non addirittura impossibile durante le ore di punta.
Questo non e' un problema nuovo, ed infatti ci sono altri servizi
affetti dallo stesso problema. Per esempio una nave in mare aperto che
tenta di accedere ad un satellite di comunicazioni (quante altre navi
possono farlo contemporaneamente ?).
Molti esperimenti diversi sono stati fatti per aggirare questo
problema del packet radioamatoriale. Una soluzione possibile puo' essere
perseguita attraverso l'uso di un ripetitore digitale full duplex (BTMA),
tuttavia ci sono diversi svantaggi a questo approccio.
In un sistema full duplex il costo dell'hadware sara' normalmente piu' alto
e il sistema occupera' due frequenze ma realizzera' la massima efficienza
[nell'originale throughput, passare attraverso] su una sola.
Un approccio migliore dovrebbe essere quello di incrementare l'efficienza
riducendo le collisioni su un singolo canale piuttosto che dividendo il
carico su due canali. L'ideale sarebbe che noi potessimo incorporare un
sistema che faccia questo con un semplice cambio del software (come una
sostituzione della EPROM nel TNC) o mediante un cambio dei parametri
operativi.
Uno dei metodi usato per tentare di risolvere il problema delle
stazioni nascoste continuando ad utilizzare una singola frequenza e'
chiamato DAMA (Demand Assigned Multiple Access).
[letteralmente, Accesso Multiplo Assegnato su Domanda, su richiesta]
Quello che segue e' una descrizione di questo metodo.
In un protocollo orientato alla connessione, un utente finale
tentera' di connettere il Master (satellite nel caso della nave) mediante
il metodo automatico ALOHA. Possono avvenire delle collisioni durante questa
fase ma esse sono tollerabili dato che sono relativamente rare. Una volta
che la richiesta di connessione e' riconosciuta del Master, la stazione
chiamante e' aggiunta a una lista di candidati e da questo punto in poi il
Master contolla tutte le stazioni connesse.
Il permesso di trasmettere i dati e' accordato attraverso indagini, sondaggi
che possono essere inclusi nei pacchetti di ACK o anche nei pacchetti
(frames) di dati trasmessi. Cosi' in questo caso un utente potra'
trasmettere solo dopo aver ricevuto il "permesso" sotto forma di richiesta
spedita dalla stazione Master.
Una volta che il permesso e' accordato diversi pacchetti possono essere
trasmessi in una volta. Tuttavia, se l'utente non risponde entro un
assegnato tempo (diciamo intorno al mezzo secondo) allora il Master assume
che la richiesta non e' stata accolta, il sondaggio e' fallito oppure
l'utente non l'ha ricevuto per qualche ragione. Il Master allora passa il
permesso di trasmettere a tutte le altre stazioni attive e una volta
completato il giro ritorna al primo utente dandogli un'altra possibilita'.
In altre parole, se l'utente (Slave [schiavo]) attualmente riceve
la richiesta e risponde con gli I-frames (frames di Informazione), il Master
non li confermera' fino al turno successivo dopo aver servito tutte le altre
stazioni attive. Se quando interrogati dal Master l'utente risponde con un
frame vuoto (Receive Ready/Final), allora il Master ridurra' la priorita'
dell'utente nella lista delle interrogazioni e lo saltera' al turno
successivo.
Come aumenta l'attivita' sulla frequenza, la priorita' delle
interrogazioni degli utenti inattivi potrebbe decrescere sempre piu', ma
quando queste stazioni rispondono con un frame di informazione (I-frame)
esse saranno riportate alla priorita' originale.
Se hai capito la descrizione appena data potresti pensare che stai
leggendo la descrizione del protocollo AX.25 livello 2 ed e' per questo che
il DAMA ha la possibilita' di operare insieme agli altri pacchetti
radioamatoriali.
L'AX.25 livello 2 contiene tutti gli elementi di protocollo che sono
necessari per implementare il DAMA e nessuna sintassi aggiuntiva e'
richiesta. La maggior parte delle nuove funzioni puo' essere ottenuta
riorganizzando i parametri operativi esistenti mentre il resto puo' essere
ottenuto apportando alcune piccole modifiche al firmware del TNC.
Allora come possiamo ora incorporare il DAMA usando il protocollo
AX.25 ?
A causa del fatto che non sono richiesti nuovi elementi di sintassi,
la descrizione seguente usera' solo i termini standard AX.25. Dato che e'
usato tanto il CSMA quanto il DAMA, tutti i prossimi riferimenti al DAMA
vanno interpretati come CSMA-DAMA.
Il termine "interrogazione, sondaggio" [nell'originale, Pool], usato in
tutto questo testo non e' riferito al bit di interrogazione contenuto nel
campo di controllo del pacchetto dei frames e questo bit rimane inalterato
per assicurare la compatibilita'. Le parti differenti del protocollo sono
descritte separatamente sotto.
┌──────────────────────────┐
│ Stabilire la connessione │
└──────────────────────────┘
Quando un BBS attende di connettere un utente, il BBS agginge l'ID
dell'utente alla sua lista di interrogazione e incomincia a spedire i
pacchetti SABM a quella stazione. Se dopo un certo numero di tentativi
nessun UA e' ricevuto, l'utente e' considerato irraggiungibile e rimosso
dalla lista dei sondaggi.
Quando un nuovo utente inizia la sequenza di connessione al BBS,
inizia inviando SABM al Master nel semplice modo CSMA copiando il metodo
esistente usato oggi. Le collisioni sono possibili durante questa fase,
cosicche' puo' essere necessario ripetere diverse volte i SABM finche' il
BBS risponde con un UA. Una volta che il BBS riconosce la richiesta di
connessione dell'utente, l'ID dell'utente e' aggiunto alla lista dei
sondaggi in un modo molto simile a quello attualmente usato dai nodi TheNet
(TheNet userlist) e il BBS (Master) ha il controllo degli uplink della
stazione utente. Dopo che l'utente invia i SABM e il BBS risponde con un UA,
l'utente risponde con un RR#0 per segnalare al BBS che la ricezione dell'UA
ha avuto successo.
┌────────────┐
│ Stato IDLE │
└────────────┘
Quando non avviene alcun trasferimento di informazioni tra l'utente
e il nodo (idles), allora il nodo invia i suoi sondaggi come un RR per il
corrispondente numero di volte. Se la risposta dell'utente e' un semplice
RR#, allora il tempo del prossimo sondaggio a questo utente verra' allungato
per evitare un carico non necessario del canale. L'esatta quantita' di tempo
aggiunto e' determinato dall'attivita' totale del canale.
Se il flusso di informazioni degli altri utenti del BBS e' elevato
(determinato dal numero di I-frames che vengono trasmessi) allora la
quantita' di tempo aggiunta prima che avvenga il prossimo sondaggio ad una
stazione inattiva e' maggiore del caso in cui l'attivita' sul canale sia
veramente poca. In questo modo quando la frequenza e' fondamentalmente
libera, i tempi di attesa sono ridotti al minimo cosicche' non avviene
nessun decremento dell'efficienza del canale. Questo e' il principio del
meccanismo di auto allineamento del DAMA, dove un canale e' sempre regolato
per assicurare la massima efficienza possibile.
Se il BBS dovesse fallire la ricezione del RR dell'utente (a causa
della collisione con un interrogazione del BBS o di una risposta RR di
un utente) allora il BBS procedera' nella lista dei sondaggi delle altre
stazioni. Il BBS tornera' e tentera' ancora questa stazione dopo aver
servito tutti gli altri utenti della sua lista. Se dopo un certo numero
di tentativi di interrogazioni questa stazione non risponde ancora, allora
essa e' considerata non disponibile al BBS ed e' esclusa completamente dalla
lista. Questo e' analogo a quei "keep-alive polls" [letteralmente, sondaggi
per mantenere vivi, per mantenere attivo il collegamento] che si hanno oggi.
┌───────────────────────────────────┐
│ Trasferimento dati: BBS => Utente │
└───────────────────────────────────┘
Non c'e' alcuna differenza tra il normale CSMA e il DAMA in questo
caso. Poiche' tocca sempre al Master (BBS) la prima mossa, esso puo'
spedire uno o piu' I-frames o una interrogazione all'utente.
L'utente confermera' immediatamente gli I-frames con un RR#, ma potra'
spedire a sua volta i propri I-frames per il corrispondente numero di volte
(dato che un corretto numero di I-frames ha la stessa funzione degli ACK nel
protocollo AX.25). Il significato del bit di interrogazione finale rimane
inalterato.
┌───────────────────────────────────┐
│ Trasferimento dati: Utente => BBS │
└───────────────────────────────────┘
Come detto prima, il BBS inviera' dei sondaggi a tutti gli utenti
che sono collegati con esso e l'utente non rispondera' finche' non ricevera'
questa interrogazione o un I-frame dal BBS. E' interessante notare che
quando un utente e' interrogato egli deve sempre rispondere con qualche tipo
di pacchetto, fosse anche un semplice RNR#. Se il BBS non sente alcun tipo
di risposta dall'utente allora suppone che qualcosa e' andato storto (come
una collisione) e si porta verso il prossimo utente nella sua lista di
interrogazioni.
Questo metodo di aspettare sempre una interrogazione prima di
trasmettere e' l'aspetto centrale usato per evitare le collisioni in una
situazione in cui esistano delle stazioni nascoste.
Questo e' in contrasto con l'usuale metodo CSMA dove diverse stazioni
possono attualmente trasmettere nello stesso tempo. In piu' il problema
dei tempi morti per evitare le collisioni e' risolto. Per tempi morti si
intende quei periodi nei quali il TNC realizza che il canale e' libero e
incomincia la trasmissione, oppure quelli in cui egli e' stato in
trasmissione abbastanza a lungo per essere riconosciuto dagli altri TNC.
Questo non e' veramente un evento raro esemplificato dal caso in cui due o
piu' TNC sono in attesa che svanisca la portante del BBS in modo che loro
possano occupare la frequenza.
Usando il DAMA il BBS non confermera' i frames ricevuti nell'istante in cui
li sente. Invece servira' prima tutti le altre stazioni connesse e dopo
tornera' indietro con un RR# alle stazioni trasmittenti gli I-frames insieme
con una interrogazione a quelle stazioni. Questa interrogazione, questo
sondaggio in pratica chiede: "Hai qualcos'altro per me ?".
┌────────────────┐
│ Disconnessione │
└────────────────┘
Se il Master intende interrompere la connessione, inviera' il solito
DISC-frame all'utente. L'utente allora rispondera' immediatamente con un
UA-frame (bit finale settato). Se il BBS non riceve l'UA e spedisce ancora
un DISC-frame, l'utente risponde con un DM-frame. Questo e' identico alla
attuale versione del CSMA.
Quando un utente vuole disconnettersi da un BBS, egli aspettera' di
spedire il suo DISC-frame fino a che non e' interrogato dal Master.
A questo punto non fa piu' differenza se il BBS risponde all'utente nel
giusto modo con un UA o prosegue con un altro ciclo di interrogazione, in
ogni caso un immediato UA e' preferito.
┌───────────┐
│ UI-frames │
└───────────┘
In CSMA come nell'ambiente DAMA, gli UI-frame [Unnumbered Information
Frame, frame di informazioni non numerate, come avviene in broadcast]
sono trattati in modo speciale. Per esempio questi frames sono usati per
portare alcune informazioni oltre il normale protocollo di traffico.
Normalmente gli UI-frames non sono mai spediti da un utente al BBS, e non e'
un buon lavoro fare l'abitudine di trasmettere UI-frames direttamente in un
QSO su una frequenza d'ingresso di un BBS. Tuttavia, al contrario che in un
sistema duplex e' possibile farlo effettivamente. Anche se cosi' facendo i
rari UI-frame ridurranno l'efficienza ai valori del CSMA, questa non cadra'
fino a raggiungere il livello dell'ALOHA come potrebbe accadere con un BBS
duplex con un QSO in corso sulla sua frequenza di ingresso.
Invece gli UI-frame generati dal BBS non sono un problema visto che tutte le
stazioni ricevono questi frame.
┌───────────────────────────────┐
│ Altri elementi del protocollo │
└───────────────────────────────┘
Siamo cosi' andati dall'inizio alla fine nella descrizione di una
completa sessione DAMA. Non abbiamo tradotto ognuno degli elementi
dell'AX.25 in uno che ha uno speciale significato per il DAMA.
Questo non e' richiesto dato che molti di loro mantengono il loro originale
significato. DM, RNR, REJ, ecc. saranno usati come fatto fin'ora.
L'unica deviazione dalla versione del puro CSMA e' il fatto che agli utenti
sara' permesso trasmettere questi frames dopo aver ricevuto il permesso dal
Master (BBS) sotto forma di richiesta, di sondaggio. Il BBS trasmettera'
questi frames solo dopo che tutti gli altri utenti sulla sua lista sono
serviti dal completamento di un ciclo di sondaggio.
┌────────────────────────────────────┐
│ Compatibilita' del DAMA e del CSMA │
└────────────────────────────────────┘
Un vantaggio del metodo DAMA e' che non richiede che ognuno debba
cambiare ognicosa tutto in una volta. Tuttavia piu' utenti convertiranno i
loro TNC a lavorare con il DAMA maggiore sara' l'incremento di efficienza.
Addirittura le stazioni che stanno aspettando di aggiornarsi possono aiutare
ad incrementare l'efficenza locale cambiando pochi parametri operativi.
Per esempio, il ritardo tra la ricezione del frame e la risposta del TNC
(chiamata alcune volte T2 o DWAIT) dovrebbe essere ridotta ad un valore
sotto 1 secondo. In piu' l'intervallo di tempo da quando un I-frame e'
spedito a quando il TNC invia un RR# per chiedere di un ACK pendente,
dovrebbe essere impostato ad un valore che e' chiaramente piu' alto che il
tempo tra due sondaggi del Master (abitualmente piu' di 30 secondi a 1200
baud).
Per beneficiare pienamente dal DAMA, sia il BBS che l'utente devono
lavorare insieme in rapporto di Master/Slave. Assumendo che il TNC
dell'utente e' capace di entrambi i modi normale e DAMA, rimane il problema
di come dire all'utente "attiva il modo DAMA".
Ci sono diversi modi che possono essere utilizzati:
1. Individuazione automatica della versione del protocollo mediante il byte
di riconoscimento del protocollo o di un riservato SSID di otto bit del
BBS (versione preferita).
2. Implementazione di uno specifico parametro del canale che controlla la
versione del protocollo.
3. Implementazione di un nuovo comando UPLINK in aggiunta al corrente
comando CONNECT.
4. Implementazione di un ulteriore elemento di protocollo quale un
SARM-frame (simile all'X.25) grazie al quale al momento della connessione
il BBS puo' avvertire l'utente delle caratteristiche estese.
Nel primo caso sarebbe sufficiente dire all'utente di passare al modo
DAMA una volta sola, al momento della connessione. Questo stato rimarra'
attivo fino alla disconnessione. Comunque dato che non ci sono campi PID nei
frame SABM questa informazione deve essere veicolata in qualche altro modo,
utilizzando per esempio il bit inattivo n. 5 del campo indirizzo dell'SSID
del Master. E' stato proposto che la versione test del DAMA ponga questo bit
a 0 per trasmettere l'informazione necessaria al TNC dell'utente.
┌─────────────┐
│ Conclusione │
└─────────────┘
La versione esistente dell'AX.25 fu stabilita nel 1982 quando il
packet radio non era cosi' diffuso come lo e' tutt'oggi. La maggior parte
delle stazioni all'inizio erano praticamente uguali e non era fatta alcuna
distinzione tra le funzioni DTE e DCE. Tuttavia con l'implementazione su
vaste aree dei networks non tutte le stazioni garantiscono le stesse
funzioni, prestazioni. Infatti oggi i nodi network sono attivi con la
funzione DCE considerando gli aspetti di interscambio di informazioni e
di controllo. Queste funzioni saranno svolte meglio con l'implementazione
del DAMA.
I metodi discussi in questo articolo possono incrementare
tremendamente l'efficienza di un canale AX.25. Un vantaggio e' evitare il
collasso del sistema che avviene con il canale sovraffollato.
Usando il DAMA, l'efficienza aumentera' continuamente fino a raggiungere il
suo massimo. Non ci sono piu' effetti negativi come quelli che accadono
usando il CSMA dove oltre un limite particolare (sopra il 60% circa)
l'efficienza e' effettivamente ridotta.
C'e' anche un forte aspetto "sociale" del DAMA, in cui perfino le
deboli stazioni possono lavorare attraverso il BBS efficientemente senza
essere coperte dalle altre stazioni piu' vicine al BBS.
E' possibile fare delle connessioni dirette con altri radioamatori
sulla frequenza di entrata diversamente dal sistema duplex. In piu' i TNC
degli utenti continueranno ad avere la funzione di digipeater compresa
negli attuali sistemi simplex.
Tutti gli elementi di protocollo mantengono il loro originale
significato il che permette ad entrambe le versioni di essere utilizzate
sulla stessa fraquenza, ma l'efficienza del canale aumentera' tanto piu'
quanti piu' utenti passeranno al nuovo metodo.
┌───────────┐
│ GLOSSARIO │
└───────────┘
DM Disconnect Mode [Modo disconnesso]
DISC Disconnect Frame [Frame di sconnessione]
FRMR Frame Reject [Frame rifiutato]
I Information Frame [Frame di informazione]
REJ Reject Frame [Frame rifiutato]
RNR Receive Not Ready [Ricevitore non pronto]
RR Receive Ready [Ricevitore pronto]
SABM Set Asynchronous Balanced Mode [Imposta il modo
asincrono bilanciato]
SARM Set Asynchronous Response Mode [Imposta il modo
asincrono di risposta]
UA Unnumbered Acknowledge [Conferma non numerata]
UI Unnumbered Information frame [Frame di informazione
non numerato]
ALOHA channel access without any coordination [Accesso al canale
senza alcun
coordinamento]
CSMA Carrier Sense Multiple Access [Accesso multiplo con
riconoscimento della
portante]
BTMA Busy Tone Multiple Access [Accesso multiplo con
il busy tone]
DAMA Demand Assigned Multiple Access [Accesso multiplo
assegnato su domanda]
DCE Data Circuit terminating Equipment [Equipaggiamento che
termina il circuito
dei dati]
DTE Data Terminating Equipment [Equipaggiamento che
termina i dati]
Protocollo orientato alla connessione:
tutti i nodi del percorso network conoscono tutte le altre stazioni che
stanno usando questo percorso, almeno ogni tanto. Questa versione richiede
maggiore potenza dei computer nel network di nodi ma evita alcuni non
necessari sovraccarichi di trasferimenti.
In opposizione a questo e' il protocollo a minor connessione, dove i
pacchetti sono semplicemente passati all'utente successivo di pari livello
(per esempio il 2 livello di trasmissione "muto" del Packet Radio).
┌─────────────┐
│ Letteratura │
└─────────────┘
div X.25 Interface DTE/DCE f Packetmodus CCITT Genf'76
div Transactions on communications IEEE
Fox, T. AX.25 Level 2 protocol specifications AMRAD
Kauffels, J. Lokale Netze R.Mueller Verlag
Schmidt, D.J. Syncrone DFUe-Protocolle mit
6809-Micro BS '81 Computern in
heterogenen Sternnetzen
Tanenbaum, A. Computer Networks Prentice Hall
╔═══════════════════════╦══════════════════════════════════════════════════╗
║ ||/|/|/| Push to test║ ░▒▓█ IW2DVL - AX25/TCP-IP Node - 1200/9600B █▓▒░ ║
║ | | ╠══════════════════════════════════════════════════╣
║ | (o)(o) > O < ║ QTH : Cinisello B. (Milano - ITALY) - JN45OM ║
║ C _) ║ E-MAIL : IW2DVL @ IW2GKO.#MI.ITA.EURO ║
║ | ,___| Release to ║ AmprNET: Max@iw2dvl.ampr.org [44.134.160.115] ║
║ /____| DETONATE ║ Max@iw2dvl-10.ampr.org [44.134.160.132] ║
╚═══════════════════════╩══════════════════════════════════════════════════╝